1. Field of the Invention
The present invention relates in general to the field of database applications and in particular to the field of database applications which support sequential batch applications. Still more particularly the present invention relates to database applications which support sequential batch applications and permit the continued evaluation and enumeration of a sequence of objects across a transaction commit, roll-back or system failure.
2. Description of the Prior Art
The storage and manipulation of data records or objects within a database application is well known in the prior art. As database applications have become larger and more complex a problem has arisen with regard to the need to apply application processing operations to a large set of data objects.
In database applications the objects which require processing are specified utilizing a non-procedural, relational calculus expression known as a "query." A named "cursor" may be associated with a query and utilized to evaluate and enumerate the query by operations known as "open" and "fetch." Typically, a plan is generated and utilized to map these cursor operations to lower level operations which operate on single relations within the database.
Examples of lower level operations include "scans" and the creation of so-called "temporary relations." Scans are enumerators over sequential access paths of single relations. An access path may comprise a sequential access scan through the records of a table in physical or numerical order, or an index scan through the keys of an index. A temporary relation contains or buffers those intermediate results which are utilized by the query plan in the construction of the query result set.
At any given time the state of an active cursor in a database application is embodied in the state of any associated temporary relations and the position of one or more access path scans. Cursor state also includes control status which may be utilized to track the progress of the query plan. In most database applications cursors are closed at the termination of a transaction. That is, upon the achievement of a state of atomicity a transaction may "commit" and release all underlying scans, temporary relations and locks associated with all cursors rendering any changes permanent. Similarly, if a transaction is terminated prior to achieving atomicity, the state of all activities therein will be "rolled-back", utilizing temporary log entries, to return the database to the previous state of atomicity represented by the last "commit."
As a result of the necessity of maintaining the atomicity of a database, a problem exists when a large number of operations must be processed. Under systems known in the prior art the entire number of records to be processed must be "locked" and maintained in that condition until all processing is complete. While this method permits some assurances that a large number of operations may be successfully accomplished, concurrent access to those records by others is prohibited during such operations.
As a result of the above several systems have been proposed in an attempt to permit the processing of a large batch of records without disrupting real time, on-line transaction processing. For example, a mechanism known as "Commit Hold" has been proposed which allows a database application to hold the locks associated with selected scans across a transaction boundary. However, there exists no method specified within this system which permits the application to specify which scans should be held. More seriously, scan positions in this system are lost in the event of a transaction roll-back. Since a roll-back may be initiated by the system without operator input the "Commit Hold" system is not generally useful.
In "Consistency of Transactions and Random Batch", ACM Transactions on Database Systems, Volume 11, Number 4, Dec. 1986, a system was proposed which constrains the ordering of batch application accesses relative to the accesses of on-line applications. This method ensures serializable execution for all involved; however, it requires a very careful synchronization between batch and on-line applications. A failure in the synchronization area within this system may result in a roll-back in either the batch or on-line application.
In View of the above it should be clear that a need exists for a database application system which permits the processing of large numbers of objects without disrupting real time, on-line transaction processing by allowing the batch application to frequently commit updates and release locks while continuing to process a set of objects defined by a query.